home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Turnbull China Bikeride
/
Turnbull China Bikeride - Disc 2.iso
/
STUTTGART
/
GAMES
/
FUNNYMINES
/
!3DMine
/
!Help
next >
Wrap
Text File
|
1995-06-16
|
35KB
|
795 lines
___________ _____
***********\ /******b.
***********:\ . /:********b )
. '-._···d**::\ /·:***·::"**B
† '-d**P:··\ /·::*** ··:"**b .
d**P:·:· \ /···:***· ··:*** .
@**(:·:· · \ / ·::*** ··::***
. † "**b:·· *****···:***· ··:***
"**b:·· ***** ·::*** ··::***
_..··'"***::·· \···:***· ··:*** †
. **b:·· ·***:.' \·::*** ··:d**P
***b:·:d**P· \·:*** ::d**B
† "********@' . \:********P
. "******P \******P' . .
~~~ ~~~~~
. ___ ___ ___
/\__\ ___ /\__\ /\ \
/%%| | /\ \ /%%| | /%%\ \ .
. /%|%| | \%\ \ /%|%| | /%/\%\ \
/%/|%|__|__ /%%\__\%/|%| |_/%%\~\%\ \
/%/ |%%%%\__\ /%/\/__// |%| /\__\\%\ \%\__\
\/__/~~/%/ //%/ / \/__|%|/%/ /~\%\ \/__/
) /%/ /%%/__/ |%/%/ /%\ \%\__\
/%/ / \%\__\ |%%/ / \%\ \/__/ †
. /%/ / \/__/ . /%/ / \%\__\
\/__/ \/__/ \/__/
. ___ ___ ___ ___ ___ ___ ___
/\ \ /\__\ /\ \ /\ \ /\ \ /\ \ /\ \
/%%\ \ /%/ / /%%\ \ /%%\ \ /%%\ \ /%%\ \ /%%\ \
/%/\%\ \%/ / /%/\%\ \%/\%\ \%/\%\ \%/\%\ \%/\%\ \
_\%\~\%\ \ _<_ /_/\~\%\ \\~\%\ \\~\%\ \\~\%\ \\~\%\ \
/\ \%\ \%\__\| |/\__\\ \%\__\\ \%\__\\ \%\__\\ \%\__\\ \%\__\
\%\ \%\ \/__/| /%/ /%\ \/__/%\ \/__/%\/%/ /%\ \/__/%\/%/ /
\%\ \%\__\/%|/%/ / \%\__\\ \%\__\ \%%/ / \%\__\|%|%%/ /
\%\/%/ /|%/%/ /%\ \/__/%\ \/__/ \/__/%\ \/__/|%|\/__/
\%%/ / |%%/ / \%\__\ \%\__\ \%\__\ |%| |
\/__/ \/__/ \/__/ \/__/ . \/__/ \|__|
3D Minesweeper
~~ ~~~~~~~~~~~
Author: A.W.Garrard
Version: 2.03 (14-Dec-94)
Purpose: Brain damage
Double-click on !3DMine to play
The classic game Minesweeper, now in 3-D
A game for people of all ages who are as bored as I was when I
wrote it
·NO tacky sound effects
·NO high speed, animated graphics (getting bored of them, yuh?)
·NO advanced GUI to baffle beginners
·ARE YOU PREPARED FOR THE INTRIGUE of working out why I could be
bothered to write this thing in the first place?
·CAN YOU STAND THE TENSION of having people stand behind you,
shouting "No, not THAT one!"?
·CAN YOUR HEART TAKE THE STRAIN of the caffeine intake from all
the coffee you can drink while the screen re-draws?
Having said that, you might enjoy it, so give it a go.
* Title MINE SWEEPER text style based on a font by Lennert Stock
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Important note:
Risc PC users with low resolution monitors should pay attention
to the section on customising their monitor definition file.
This game will not work in low resolution on a Risc PC without
this change being made.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Game mechanics
~~~~ ~~~~~~~~~
This program has on-line help, but for people who would rather
read this in their favourite text viewer before use, details
of the game are provided below...
Gameplay: it's normal minesweeper, only 3-D.
If that doesn't help, here is a brief synopsis of minesweeper:
Minesweeper is a game which is played on a grid of cells. Each
cell may or may not contain a mine. To start with, you do not
know the contents of the cells.
The aim of the game is to flag all the cells which contain
mines. If you think a cell does not contain a mine, you can
uncover it. If you uncover a cell which contains a mine, you
lose the game. If the cell which is uncovered is safe, it will
change to show you how many cells adjacent to it (including
diagonals) contain mines. You cannot clear a cell which has
been flagged or queried.
If you change your mind about whether a flagged cell contains a
mine, you can un-flag it again. You only have as many flags as
there are mines, and the game finishes when you have no flags
left. If you have all the mines flagged at this point, you win,
otherwise (i.e. you have a flag wrongly placed) you lose.
You can also place a query on a cell. You cannot flag a cell
which has been queried, or query a cell which has been flagged.
The only purpose of a queried cell is to help you calculate
whether other cells may contain mines in a complex arrangement-
queried cells show up amber, and have no other effect on the
game. Cells can be un-queried when you have done with them, and
you may query as many cells as you like.
Cells which are not yet uncovered are shown in blue
Cells which are queried are shown in amber
Cells which are flagged are shown in red
Cells which have been uncovered are shown as follows:
No adjacent mine - cell not plotted (invisible)
Adjacent mines - cell plotted in black with red outline and
with a letter in red indicating number of mines: A=1, B=2 etc.
There are readouts on the main screen showing the coordinates
of the cell currently displayed under the mouse pointer, the
number of mines around this cell, and the number of flags
which the player has left.
The three-dimensional game grid may be rotated at will. Because
the grid is 3-D, it is possible for some cells to be completely
obscured by others. To remedy this, it is possible to request
that only a portion of the grid be displayed by specifying a
range of coordinates to be displayed. The help screen indicates
the current numerical values of this range, and the grid box
shown on the help screen encloses only the current range, thus
providing a more graphical indication. The limits may be varied
by use of the keyboard, with keys increasing or decreasing the
upper and lower limits of the range along each axis. The whole
grid is always displayed at the start of a game.
The game uses quite a large amount of memory, and, especially
for large grids, re-draw may take a few seconds (an hourglass
percentage is displayed indicating progress). The grid will
update faster if there are less cells to display - to increase
speed, uncover cells as soon as you can (empty cells draw faster
than unknown ones) and use QwErTy (or equivalents) to reduce the
size of the displayed grid. Use of the help screen is also
recommended to speed up rotations and resizing.
When the player uncovers a cell which is not adjacent to any
mines, the program will clear the grid out from that cell until
the boundaries of all uncovered regions are again adjacent to
mines. (This saves time, and would be trivial to do yourself,
since all the cells around such a cell are by definition safe).
When starting, the player is asked for a grid size and no. of
mines. The number of mines cannot exceed the number of cells
in the grid, excluding corner points (no mine will be placed
in a corner cell).
The x coordinate of the grid size must be a multiple of 8 (for
storage reasons).
It is recommended that the game is first played on an 8x5x5 grid
with 5-10 mines until you are familiar with the controls.
Mouse buttons function as follows:
_____________________________
| | |
| Flag/ | |
| unflag | |
|_________| |
| | |
———————————| Query/ | |
———————————| unquery | |
|_________| |
| | |
| Uncover | |
| cell | |
|_________|___________________|
Select - uncover cell
Menu - query cell (for user calculation purposes)/unquery it
Adjust - flag/unflag cell
In addition, there the following short-cuts are available:
Shift+Select on a lettered cell which has as many flags next to
it as it has mines clears all remaining cells around the cell
Shift+Adjust on a lettered cell which has as many blank cells
next to it as there are mines left to be flagged around it
flags all remaining blank cells around the cell
These short-cuts are best understood by experiment.
Default keys function as follows:
q moves the x coord lower bound down
Q moves the x coord lower bound up
w moves the x coord upper bound down
W moves the x coord upper bound up
e moves the y coord lower bound down
E moves the y coord lower bound up
r moves the y coord upper bound down
R moves the y coord upper bound up
t moves the z coord lower bound down
T moves the z coord lower bound up
y moves the z coord upper bound down
Y moves the z coord upper bound up
z rotates the grid to the left slowly (about the y axis)
Z rotates the grid to the left quickly
x rotates the grid to the right slowly
X rotates the grid to the right quickly
' rotates the grid up slowly (about the x axis)
" (@ on a Risc PC) rotates the grid up quickly
/ rotates the grid down slowly
? rotates the grid down quickly
o rotates the grid to the left slowly (about the z axis)
O rotates the grid to the left quickly
p rotates the grid to the right slowly
P rotates the grid to the right quickly
The above keys may be redefined, and the settings saved, but
saved settings must be explicitly loaded since the program
will default to the above settings each time it is run.
<space> swaps between the main and help screens
<Esc> restarts and <Ctrl>+<Esc> exits the game
The current keys are displayed on the help screen.
The disc from which the game was loaded must be left in the
drive while playing - it will be accessed at the start of each
new game. This is not an attempt at anti-piracy, merely a
consequence of the way the program works; a large enough ADFS
buffer will suffice instead, or the game may be run from a
ram disc.
Files are provided in the !3DMine directory to support The
Serial Port joystick interface. Please read the LeadEdSrc source
file to see how to use joysticks with the game. To open the
!3DMine directory and get access to these files, hold down
<Shift> and double-click on the !3DMine application. Once the
joystick file has been loaded, the game should be run as normal.
The Vertical Twist joystick interface does not work (at time of
writing) on the Risc PC - this is nothing to do with !3DMine,
and the author will be pleased to hear from anyone who has got
the joystick interface to work on the new machine.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Machine requirements:
~~~~~~~ ~~~~~~~~~~~~
The program should run on any 32-bit Acorn machine with RISC OS
(although RISC OS 3's ColourTrans will make use of dithering).
I have not been able to test the program on any OS versions
except 3.5, 3.11 and 2.00 (low resolution only), or on any
machines with less than 4Mb, but can't see any reason why it
shouldn't work on any others. The latest version has only been
tested on a RISC OS 3.5 machine, but no changes have been made
which should compromise functionality on earlier computers.
Although memory usage improved radically in version 1.14, the
high resolution version of the game still requires a 2Mb machine
(although it will fit in one far more comfortably than previous
versions). The low resolution version will run on a 1Mb RISC-OS2
machine, but modules may need to be unplugged to get it to run
on a 1Mb RISC-OS3 machine. The program will not run on an A305
which has not been expanded. For similar reasons, effort has not
been expended to get the program to work on Arthur, especially
since Arthur can't display the right screen mode. Due to the
speed (or lack of it) at which the program runs, an ARM3 (or
later) is recommended, but then one always is. There have been a
lot of code optimisations made in the hope that one is not
required but is a luxury.
In high resolution mode, the program runs in mode 27 (640x480,
16 colour VGA) and so should work on VGA, SVGA and MultiSync
monitors, and on the A4's LCD display - although on the latter
(and other monochrome displays), colours will obviously be
harder to distinguish between, especially since I did not have
an A4 available when palette choosing. Owners of such machines
may have to resort to the read-out at the top of the screen to
tell them what is under the mouse pointer; anybody who can
provide a suitable alternative palette with more contrast on the
A4, but still provides intuitive colours on a colour display,
please let me know and I will include it in the next update.
Although the game may be played in 'low resolution mode', the
display quality suffers significantly. The low resolution option
was only written for compatibility, since it allows the !3DMine
to be run on a 1Mb machine (just) as well as just on a normal
monitor. The game is playable in this state, but the high-
resolution version is recommended where available (the layout of
the user interface is better and the cells are much clearer and
less lumpy). Mode 27 was chosen as the next most 'standard'
resolution which most monitor types can display (but 'normal' &
high-res mono monitors can't). The low resolution option runs
in a custom mode 112, which is mode 12 but with the resolution
tweaked to 640x240.
If the program is run on a machine with a low resolution monitor
or if insufficient memory is available to run in high resolution
mode then the program will automatically run in low resolution
mode. It is possible to force the game into low resolution mode
by holding down <Return> when the program is run. The low-res
version of the game does have slightly faster update, so if the
user is willing to forfeit display quality in return for this
speed increase, this facility may be useful (although personally
I wouldn't think it was worth it).
On a hi-res mono monitor (type 2), the program will probably
attempt to run in a different mode to the one it thinks it is
running in, and therefore even if it doesn't crash it will not
be playable. C'est la vie.
The program could have been written to allow various screen
modes, and even to run in the desktop. The reasons it wasn't,
in increasing order of importance, are:
a) It would slow it down and require even more memory.
b) It would stop me using shadow screens etc. which would mean
more complex coding.
c) I couldn't be bothered (I have a degree to do too, you know).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Risc PC screen modes and customising monitor definition files:
~~~~ ~~ ~~~~~~ ~~~~~ ~~~ ~~~~~~~~~~~ ~~~~~~~ ~~~~~~~~~~ ~~~~~
On a Risc PC, the game attempts to run in 640x480, 16 colours.
If there is insufficient memory for this, if this mode is not
defined in the monitor definition file currently in use (e.g.
the machine is in use on a low-resolution monitor), or if the
<Return> key is pressed when the program is run, the game will
try to use a 640x240 16 colour mode. This section provides
information on that mode - if you never intend to run the game
in low-resolution mode, you can ignore the rest of this section.
If you use an AKF50, AKF52, AKF60 or AKF85 monitor definition
file, modified versions providing definitions for the customised
640x240 low resolution mode which !3DMine uses are provided in
the !3DMine.3DMMDF directory distributed with this game; shift-
double-click on the !3DMine application to open its directory.
To install these definition files, copy this directory into the
$.!Boot.Resources.Configure.Monitors on your hard disc (shift-
double-click on the !Boot application to open it, then double-
click on the other directories to open them). Then double click
on !Boot to configure the new MDFs. Click on the screen icon in
the configuration window, then, from the menu to the right of
'Monitor type' in the Screen window, choose the appropriate MDF
out of 'AKF50 3DM', 'AKF52 3DM', 'AKF60 3DM' & 'AKF85 3DM'. Then
click on 'Set' in the Screen window. Your computer should now be
correctly set up so that !3DMine can use its custom modes. If at
any point you change which monitor definition file you use,
remember to change back to this one before running !3DMine in
low-resolution mode. If you can use the provided definition
files, you can afford to ignore the rest of this section.
If you have a different type of monitor, you may have to make
some changes to the definition file you do use, because of the
non-standard 640x240 mode which the game uses.
This 640x240 mode is unlikely to be defined as default in your
monitor definition file. Hence, if you wish to use !3DMine in
low resolution mode, you must make some changes to your MDF. To
do this, look in the $.!Boot.Resources.Configure.Monitors folder
on your hard disc - shift-double-click on the !Boot application
to open it, and double-click on the other directories to open
them. In it are a number of directories containing monitor
definition files, which are simply text files which tell the
computer what signals to send the monitor. You need to find the
file which contains the monitor definition which you use - for
example, if you are using the standard AKF60 monitor then the
monitor definition file which you use may be called 'AKF60' in
the Acorn directory. When you have found this file, load it
into a text editor (e.g. !Edit). If you have the correct file,
it should contain the following section near the top, possibly
after some lines beginning with # characters:
file_format:1
monitor_title:nnnnnnnn
Where nnnnnnnn is the name of your monitor, which appears in the
title of the mode selector window. Change the nnnnnnnn to give
some indication that this file has been modified for !3DMine -
for example, 'Acorn AKF60' could be called 'Acorn AKF60 3DM'.
Then go down through the file until you find the line:
# 640 x 250
or:
# 640 x 256
(preferably the former). There may be another comment after the
numbers. Copy the section between this line and the line which
reads 'endmode' (inclusive) to the end of the file and change
the 250 or 256 to read 240. Next you need to change the line
which reads:
y_res:n
(where n is 250 or 256 depending on which definition you have
copied) to read:
y_res:240
Finally you need to look at the v_timings line. It will contain
something of the format:
v_timings:s,bp,tb,scr,bb,fp
where s,bp,tb,scr,bb and fp are numbers telling the computer
how many scan lines make up the sync, back porch, top border,
screen, bottom border and front porch respectively. You do not
need to know the details of how these work.
The scr value needs to be changed to read 240, but in order to
ensure that the mode still works, you will need to increase the
bottom and top borders so that the total number of scan lines
stays the same. To do this, if 'scr' was originally 250, add
5 to tb and bb (to evenly distribute the extra 10 lines between
the two borders and keep the screen centred). If 'scr' was 256,
add 8 to tb and bb.
As an example, taking the standard AKF60 definition file, the
copied section originally read:
# 640 x 250 (70Hz - Modes 3,11,14)
# Low band
startmode
mode_name:
x_res:640
y_res:250
pixel_rate:25175
h_timings:88,22,22,640,22,6
v_timings:2,109,0,250,0,88
sync_pol:2
endmode
and should be changed to
# 640 x 240 (70Hz - Modes 3,11,14) <- 250 changed to 240
# Low band
startmode
mode_name: <- this is blank
x_res:640
y_res:240 <- 250 changed to 240
pixel_rate:25175
h_timings:88,22,22,640,22,6
v_timings:2,109,5,240,5,88 <- borders 5, screen 240
sync_pol:2
endmode
If there is anything following the ':' on the mode_name line,
the extra should be removed.
There is nothing special about the 640x256 and 640x250 mode
definitions - you can base your new mode on any original mode,
but since these are standard modes which are likely to exist and
be correctly adjusted for your monitor, these are the suggested
sizes to use. Note that the borders cannot be negative, so the
original mode must be at least 240 pixels vertically. You do not
have to start with a mode which is 640 pixels horizontally, but
you must pad out the corresponding borders and make the other
changes needed to alter the screen width, so unless you know
what you are doing, this is not recommended.
When you have finished making your changes, save the monitor
definition file under a new name (so that it does not write over
the old one, in case there is a problem). You will then have to
run the !Boot application to get the configuration options. When
you have done this, click on 'Screen' and from the menu to the
right of 'Monitor type', choose the monitor definition file
which you have created. Click on 'Set' in the Screen window, and
the computer will know about the screen mode which it needs for
!3DMine.
If there is a problem with the new definition file, one of three
things will happen. Firstly, the configure application may
complain when it tries to scan for new monitor definition files
(and the new definition will not appear in the menu). Secondly,
!3DMine may not be able to find the screen mode it needs, and
will refer you back to this document. Finally, the mode may be
defined but your monitor will not be able to display it, and
instead produce a distorted picture or power-down. Press <Ctrl>+
<Esc> twice and then <Space> to quit !3DMine and return to the
desktop in this last case. Check the definition file again -
there should not be a circumstance under which these changes
will not work. For more details on changing monitor definition
files, you are referred to my article in the October '94 edition
of Archive magazine on 'Creating Monitor Definition Files'.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Revision history:
~~~~~~~~ ~~~~~~~
Conceived Feb 18th 1994 (may have been 17th)
Version 1.00 Feb 19th
·complete in BASIC, but no auto-clear
Version 1.01 Feb 21st
·auto-clear about cells non-adjacent to a mine added
·final print-out of maze added
Version 1.02 Feb 21st
·m/c 'z-buffer' implemented to replace BASIC - much faster
·auto-clear amended (now does diagonals, as original)
Version 1.03 Feb 21st
·added rotation about z axis (on request) -
may need guide for rotation to be added later (see 1.06)
Version 1.04 Feb 22nd
·minor bug fix -
now detects #surrounding mines correctly for larger mazes
Version 1.05 Feb 23rd
·minor alteration - now all rotations are relative to screen
axes rather than those of the original grid
Version 1.06 Feb 25th-26th
·help screen added - also provides faster interaction
·auto-clear algorithm changed (now slower, but handles 16x16x16)
·crude timing added
Version 1.07 Feb 27th
·auto-clear improved - quite a lot faster, but still slower
than original
·timing now ignored redraw time
·restart option provided
Version 1.08 March 1st
·fancy graphics on win/lose and startup provided
Version 1.09 March 2nd
·help screen at start added, graphics improved (slightly)
Version 1.10 March 2nd
·help screen at start updated; bug on return fixed
·<Esc> during game now returns to start screen (quits on start)
·grey shading of uncovered cells removed, since it wasn't really
noticeable and was only slowing the program down
·indication of reason for re-draw added
(mainly to avoid confusion over Caps Lock)
Version 1.11 March 3rd
·depth cueing on final maze printout added
·facility to see main maze display from final printout added
Version 1.12 March 12th
·VDU 24 and range clipping on drawn cells after single cell
update (drastic update speed improvement)
·final screen key done
·first release version
Version 1.13 March 18th
mostly bug fixes from version 1.12 (which was rushed):
·fixed bug on clipping (now clears rectangle in z-buffer - this
only matters where a single cell which is not adjacent to any
mines is cleared and nothing else is plotted over where it was;
but it might have caused a crash *BLUSH* - and in a released
version too!)
·clearing for text improved (doesn't leave spare text on screen)
·now notes cells which are transparent, so it's not necessary to
count surrounding mines for uncovered cells on every redraw -
another significant speed increase on redraw, when the grid has
been partially or mostly cleared
Version 1.14 March 29th
lots of improvements the day after a HENSA upload - NOT clever
·code for writing to z-buffer greatly improved -
now more convoluted, but faster (removed lots of MULs)
·z-buffer is now 16-bits deep, not 32 (not much point having 32
bit buffer when you can only have 4097 values in it) - could
be 13 bits (not 12 :-( ) or 12+1, but would require far more
coding; probably still wouldn't fit on 1Mb machine (comes just
short of a meg with screen memory, but you need the OS) so I
won't bother - I've just saved 600k, after all
·final grid display altered to show more specifics
·tested with !VDUTask (works, surprisingly, but not very stable)
Version 1.15 March 31st
·grid representation changed (now memory block, not int. array)
- facilitates future m/coding (e.g. clearing code)
·grid clearing code now in assembler - MUCH faster, even if a
bit badly coded (delay now < 1 sec vs 45 secs for 16x16x16 in
version 1.14, on a 25MHz A5000; redraw still 30 secs tho'.)-: )
·slight improvement to help screen GUI
·<ESC> while exploding now quits (<ESC><ESC> is fast exit)
Version 1.15LR March 31st
·as version 1.15, but runs on 'normal' monitors in custom mode
·selector program automatically chooses between 1.15 and 1.15LR
(based on monitor type)
Version 1.16 April 6th
·combines 1.15 and 1.15LR into one program to allow for easier
update (so I don't have to change two programs each time)
·matrices for position calculation are now integer, using fixed-
point, in preparation for more heavily ARM-coded releases -
N.B. initial loss of accuracy, but 15 binary places seems to be
enough (10 isn't); could go back and only convert to fixed-
point at final stage, if necessary
Version 2.00 April 14th
·now uses floating point for the position calculation again, but
converts to integer for plotting (retains accuracy, but allows
use of machine-code routines)
·plotting routines are now machine-coded - significant speed up
·cells now plotted with sprites, not circles - a bit faster
·keys now user-definable (with, unfortunately, a bit of naughty
code to retain settings)
·short-cuts (shift-adjust and shift-select on lettered cells)
added, having found a RISC-OS version of Minesweeper which has
this facility
·program no longer needs MemAlloc, and assigns itself suitable
amounts of memory if it can (not quite perfectly, and there are
better ways of doing it, but I only have Arthur PRMs so I claim
ignorance)
·the program will now generate a new copy of the custom screen
mode module if it needs one and can't find it, although it does
still need to save it in the same directory as the program
·!RunImage is now self-contained, and the !Run file now does
nothing significant
·<Esc> now always returns to the start of the program; quit has
been changed to <Ctrl>+<Esc> (twice to quit quickly)
·joystick files provided (only keyboard equivalents)
Version 2.01 April 19th
·bug fix (I'd accidentally typed : not + on range setting)
·bug fix - can now have true maximum number of mines for a grid
·hourglass added to mine filling routine (can be slow)
Version 2.02 December 3rd
·now uses @ instead of " on Risc PCs (to compensate for changed
keyboard layout) as default
·handles correct modes (low resolution and custom 640x480) on
Risc PCs
·help on creating appropriate Risc PC monitor definition files
and sample files for default distribution MDFs provided
·found out how to do proper memory allocation - but since the
existing code works, it hasn't been changed
·Help file updated December 13th - now has prettier title and
mouse button diagram; also changed my address to home (since
I won't be at college next year)
Version 2.03 December 14th
·Help file updated to include stereogram and ACTUALLY TELL YOU
HOW TO PLAY MINESWEEPER (bit of an omission that)
·!3DMine application sprite improved
·Now doesn't change from 640x480 <n>Hz to mode 27 on a Risc PC -
hence the monitor doesn't re-sync every time the game is re-
started; also changed mode handling on errors to go into the
current mode (which will always be okay) instead of 27 or 0
·Help file updated December 15th to correct typos and improve
the clarity of the instructions for changing MDFs
·Help file updated January 10th 1995 to correct and improve
stereogram and provide instructions for people without editors;
application sprite also improved again - happy new year!
·Help file updated January 28th - whoops, got the stereogram
backwards (don't believe I didn't notice)!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Boring bit
~~~~~~ ~~~
As the author of this program, I have legal say in what you may
do with it. As such, I don't really mind what you do to it for
your own use. However, should it be passed on to anyone I would
ask that it be passed on in its original form, with all the
original files (at least this !Help file, the !Run file, the
!Sprites file, the LeadEdSrc and SerPort/JS joystick files, the
monitor defition files in the 3DMMDF directory - AKF50 3DM,
AKF52 3DM, AKF60 3DM and AKF85 3DM - and the !RunImage itself)
present and unchanged. If you wish to let an improvement be
distributed, please mail me with the suggested changes so that
they can be officially implemented in the next version, since I
would like the program to maintain some standard form when it
first reaches people.
You may distribute this program as you wish, with the constraint
that it may not be distributed for money other than the price of
the medium on which it is supplied; this game is public domain
and I do not give permission for it to be sold.
I take no responsibility for any damage caused by this software
or addiction (unlikely) to it. The program was virus-free when
it left me; I am not responsible for its state when you received
it.
This program is NOT shareware. It IS free software. However, if
anybody wishes to send some money to the author (who is an
impoverished student) because they enjoyed the game so much,
then it will be gratefully accepted. I will willingly provide a
copy of the most recent version to anyone who requests it, so
long as my costs are covered. Having said that, I have no plans
for a later version than this, except for debugging.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Anybody being critical of my programming: yes I know the way I
plot the grid is a little slow, but it is not worth optimizing
it properly (eg by writing custom circle drawing routines & by
writing direct to the z-buffer, rather than using a sprite for
each cell and using a shadow screen mask in the buffer-writing
routine). Look on the bright side: until I wrote version 1.16,
I was using CIRCLE and CIRCLEFILL instead of sprite plots. The
buffer is there so that calculation of which cell is under the
pointer is responsive enough, since real-time techniques which
don't use buffers would require much more processing power, or
at best could be inaccurate without a considerable increase in
the complexity of the code. This would probably be more effort
than it is worth, at least as far as I am concerned.
To purists: my 'z-buffer' isn't actually a z-buffer, but it is
used in a related way, so it seemed like a suitable name.
Apologies for any characters which appear incorrectly on early
machines when reading this help file; I'm afraid you will have
to upgrade to get the full effect. :-)
Please report any bugs or suggestions which wouldn't take long
to implement (I don't have much time on my hands just now) to:
Andrew Garrard
25 Millfield
Eye, Suffolk
IP23 7DE
or, preferably, AWG1000@phx.cam.ac.uk or AWG1000@cus.cam.ac.uk
if it's before the end of June 1995.
I dedicate this program to my best friend and fiancée, Stephanie
Keele. It was her addiction to !Mine which started me on this
project, and I am very thankful that she withstood me being
antisocial by programming at her. I am also grateful for the
suggestions she has given on the user interface, and assistance
she provided with debugging, and for her being so generally
wonderful. It's just a pity that she still prefers !Mine to
!3DMine. (*SIGH*) :-(
. . , . , . . .
'·.··'··.' \.··'··./ '.··'··.·'
: ` ’ : : ' ’ : : ' ' :
-: • :- -: • :- -: • :-
: .: : . : : . :
.··.: ..·. /·.: ..·\ ,·:. ..··.
': ' : ' :
Gratuitous stereogram - supposedly of mines
Too see this stereogram, place your nose close to your screen
and try to look at the left hand mine with your left eye, and
the centre mine with your right eye (or the centre and right
hand mines, respectively). Try to get the circular outlines
of the mines to overlap by pulling your head back slowly. If
you can do this, you should get the illusion that the •
characters stick out of the mines towards you as spikes, as
will other 'points' - there are also some 'points' sticking
away from you. Apparently about 50% of people can see this kind
of illusion, so if it doesn't work for you, sorry. Well, it's
not like you paid for it or anything. :-)
If this scrolled by too fast to read, hold down <Ctrl> to
slow down scrolling and <Ctrl>+<Shift> to stop the text.
Alternatively and preferably, load the file into an editor
(e.g. !Edit in the RISCOS 3 Apps folder or on the RISCOS 2
applications discs, or !Zap - in the public domain).
If you do not have an editor available, try this:
Make sure the filer window containing !3DMine is open.
Press F12 to get a command line prompt and type:
TYPE <directory>.!3DMine.!Help
where <directory> is the text in that window's title bar.
When you have read the text, press <Return> to finish.
